On the Content Security Policy Violations due to the Same-Origin Policy
Dolière Francis Some Nataliia Bielova Tamara Rezk Université Côte d’Azur Université Côte d’Azur Université Côte d’Azur Inria, France Inria, France Inria, France [email protected] [email protected] [email protected]
ABSTRACT Modern browsers implement different security policies such as the Content Security Policy (CSP), a mechanism designed to mitigate popular web vulnerabilities, and the Same Ori- gin Policy (SOP), a mechanism that governs interactions between resources of web pages. In this work, we describe how CSP may be violated due to the SOP when a page contains an embedded iframe from the same origin. We analyse 1 million pages from 10,000 top Alexa sites and report that in 94% of cases, CSP may be vio- lated in presence of the document.domain API and in 23.5% of cases CSP may be violated without any assumptions. During our study, we also identified a divergence among browsers implementations in the enforcement of CSP in sr- cdoc sandboxed iframes, which actually reveals an inconsis- Figure 1: An XSS attack despite CSP. tency between the CSP and the HTML5 specification sand- box attribute for iframes. To ameliorate the problematic mitigate cross site scripting attacks (XSS), data leaks at- conflicts of the security mechanisms, we discuss measures to tacks, and other types of attacks. CSP allows developers to avoid CSP violations. specify, among other features, trusted domain sources from which to fetch content. One of the most important features 1. INTRODUCTION of CSP, is to allow a web application developer to specify Modern browsers implement different specifications to se- trusted JavaScript sources. This kind of restriction is meant curely fetch and integrate content. One widely used specifi- to permit execution of only trusted code and thus prevent cation to protect content is the Same Origin Policy (SOP) [1]. untrusted code to access content of the page. SOP allows developers to isolate untrusted content from a In this work, we report on a new fundamental problem different origin. An origin here is defined as protocol, do- of CSP. CSP defines how to protect content in an isolated main, and port number. If an iframe’s content is loaded page. However, it does not take into consideration the page’s from a different origin, SOP controls the access to the em- context, that is its embedder or embedded iframes. In par- bedder resources. In particular, no script inside the iframe ticular, CSP is unable to protect content of its corresponding can access content of the embedder page. However, if the page if the page embeds (using the src attribute) an iframe iframe’s content is loaded from the same origin as the em- of the same origin. The CSP policy of a page will not be bedder page, there are no privilege restrictions w.r.t. the applied to an embedded iframe. However, due to SOP, the embedder resources. In such a case, a script executing in- iframe has complete access to the content of its embedder. side the iframe can access content of the embedder web- Because same origin iframes are transparent due to SOP, page. Scripts are considered trusted and the iframe becomes this opens loopholes to attackers whenever the CSP policy transparent from a developer view point. A more recent of an iframe and that of its embedder page are not compat- specification to protect content in webpages is the Content ible (see Fig. 1). Security Policy (CSP) [15]. The primary goal of CSP is to We analysed 1 million pages from the top 10,000 Alexa sites and found that 5.29% of sites contain some pages with Permission to make digital or hard copies of all or part of this work for personal or CSPs (as opposed to 2% of home pages in previous stud- classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation ies [16]). We have identified that in 94% of cases, CSP on the first page. Copyrights for components of this work owned by others than the may be violated in presence of the document.domain API author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or and in 23.5% of cases CSP may be violated without any republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. assumptions (see Table 3). During our study, we also iden- WWW ’17 April 3–7, 2017, Perth, Western Australia tified a divergence among browsers implementations in the enforcement of CSP [24] in sandboxed iframes embedded ⃝c 2016 Copyright held by the owner/author(s). Publication rights licensed to ACM. ISBN 978-1-4503-2138-9. . . $15.00 with srcdoc, which actually reveals an inconsistency between DOI: 10.1145/1235 the CSP and HTML5 sandbox attribute specification for iframes. We identify and discuss possible solutions from the Directive Controlled content developer point of view as well as new security specifications script-src Scripts that can help prevent this kind of CSP violations. We have default-src All resources (fallback) made publicly available the dataset that we used for our style-src Stylesheets results in http://webstats.inria.fr/?cspviolations. We have img-src Images installed an automatic crawler to recover the same dataset font-src Fonts every month to repeat the experiment taking into account connect-src XMLHttpRequest, WebSocket or the time variable. An accompanying technical report with EventSource a complete account of our analyses can be found at [14]. object-src Plug-in formats (object, embed) In summary, our contributions are:(i) We describe a new report-uri URL where to report CSP violations class of vulnerabilities that lead to CSP violations. (Sec- media-src Media (audio, video) tion 2). (ii) We perform a large and depth scale crawl of child-src Documents (frames), [Shared] Workers top sites, highlighting CSP adoption at sites-level, as well frame-ancestors Embedding context as sites origins levels. Using this dataset, we report on the possibilities of CSP violations between the SOP and CSP Table 1: Most common CSP directives [19]. in the wild. (Section 3). (iii) We propose guidelines in the design and deployment of CSP. (Section 4). (iv) We A whitelist can be composed of concrete hostnames (third.com), reveal an inconsistency between the CSP specification and may include a wildcard * to extend the policy to subdomains HTML5 sandbox attribute specification for iframes. Differ- (*.third.com), a special keyword ’self’ for the same host- ent browsers choose to follow different specifications, and we ing domain, or ’none’ to prohibit any resource loading. explain how any of these choices can lead to new vulnera- Restrictions on scripts Directive script-src is the bilities. (Section 5). most used feature of CSP in today’s web applications [19]. It allows a programmer to control the origin of scripts in 2. CONTENT SECURITY POLICY AND SOP his application using source lists. When the script-src The Content Security Policy (CSP) [15] is a mechanism directive is present in CSP, it blocks an execution of any that allows programmers to control which client-side re- inline script, JavaScript event handlers and APIs that ex- sources can be loaded and executed by the browser. CSP ecute string data code, such as eval() and other related (version 2) is an official W3C candidate recommendation [24], APIs. To relax the CSP, by allowing the execution of in- and is currently supported by major web browsers. CSP is line more restrictive than the CSP of the parent. In the next 3 ... example we show that this requirement does not necessarily 4 prevent possible CSP violations due to SOP. 5